Governments and businesses are increasingly interested in issuing virtual ID cards to citizens, customers and employees. The virtual ID cards may be provided on mobile phones, or other similar personal computing device, and displayed using an app running on the device. In some cases, what verifying authorities need to know is not just the identity of the person before them, but instead, other information about the person such as the age of the person or the state of the licenses associated with that person (e.g., revoked, active, etc.). For example, a license holder may present their driver's license to service provider to prove the age of the license holder in connection with purchasing liquor even though the purchase of liquor is unrelated to the issuance by a state of the driver's license. Generally, a state issued driver's license is considered proof of identity and/or age in a number of situations unrelated to driving an automobile. The same may be true, perhaps to a lesser extent, to other types of licenses/credentials issued by government or other authorities.
There is a desire to format virtual ID data according to international conventions to facilitate interoperability, especially for system components from different vendors. Many of the conventions use standards, such as ISO18013, to encode the data in a set of numbered Data Groups (DG1 . . . DG16), some of which may be mandatory and some not. Each Data Group may be specified to contain a set of data elements so that, for example, DG1 may contain data such as Family Name, Given Names, Date of Birth, etc. Each data element may be represented using Type-Length-Value (TLV) coding or another appropriate mechanism. In some cases, at least one of the data groups may include hashes of the other data groups. Thus, for example, if there are twelve data groups, one of the data groups may contain eleven hashes, one for each of the other data groups. This same data group may contain a signature that is a function of the 11 hashes. Additionally, the signature may be provided by the trusted/issuing authority and may incorporate public/private key elements of the trusted authority within the signature. The digital signature and/or hashes may be provided by a party that is trusted/known to a user of the data. For example, if the data represents a virtual driver's license, a digital signature for the hashes may be provided by the Department of Motor Vehicles.
A virtual ID, such as a driver's license, may be used for many purposes. For example, a US driver's license may be used for a number of situations where it is desirable for a license holder to identify themselves, such as renting an automobile or checking in to a hotel. However, encoding data into data groups with fixed data elements means that the recipient must receive all of the data in each group that is provided by the license holder in order to be able to verify the data using the corresponding digitally-signed hash value. However, there may be situations where a Data Group that contains necessary information also contains information that the license holder does not want to provide to the recipient. For example, there may be only one Data Group that contains the license holder's date of birth, but the license holder may not want to provide that Data Group to a bartender (to prove age) if the group also contains, for example, the license holder's home address. Although it may be possible to create one or more “custom” Data Groups for different situations, there may only be a limited number of Data Groups available for this purpose, especially in situations where it is desirable to adhere to a standard for the virtual ID.
Accordingly, it is desirable to provide a mechanism to allow formation of custom Data Groups to be used with a virtual ID while still maintaining consistency with a standard.